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Sir: 

Appellants hereby appeal to the Board of Patent Appeals and Interferences from the 
Examiner's final rejection of claims 1-3 and 5-33 in the final office action mailed on January 22, 
2008 in the above-identified patent application. A timely notice of appeal was filed on May 22, 
2008. 
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1. REAL PARTY IN INTEREST 

The real party in interest of the above-captioned patent application is the assignee, 
INTEL CORPORATION. 

2. RELATED APPEALS AND INTERFERENCES 

None. 

3. STATUS OF THE CLAIMS 

A. Current Status of Claims 

1. Claims pending: 1-3 and 5-33. 

2. Claims canceled: 4 and 34. 

3. Claims withdrawn from consideration but not canceled: None. 

4. Claims allowed: None. 

5. Claims rejected: 1-3 and 5-33. 

6. Claims objected to: None. 

B. Claims on Appeal 

Claims 1-3 and 5-33 are the subject of this appeal. All of these claims were rejected in the 
final office action mailed on January 22, 2008 (hereinafter, "the final office action"). An 
amendment after final was filed on March 21, 2008 (hereinafter "the amendment after final") that 
provided further argument regarding the rejected claims, but which had no claim amendments, 
cancelations, or additions. In response to the amendment after final, the Examiner mailed an 
advisory action (hereinafter ''the advisory action") that provides a more explicit analysis in support 
of the rejections in the final office action. The present appeal brief addresses the arguments and 



factual findings made by the Examiner in both the final action and the advisory action. No other 
claims are pending. 

4. STATUS OF AMENDMENTS 

None. 

5. SUMMARY OF THE CLAIMED SUBJECT MATTER 

Independent claim 1 of the present application is directed to a client device comprising: (a) 
an ad-hoc client to manage connection of said client device to an ad-hoc wireless network; (b) a 
DHCP client to send a DHCP discover message in response to a command from said ad-hoc client; 
and (c) a tinyDHCP unit to sense said DHCP discover message and allocate an IP address for the 
client device in response thereto. 

For claim 1, examples are disclosed in the specification as filed at, for example, page 4, line 
14 to page 6, line 2 and Figs. 2, 3, and 4. The exemplary embodiments disclose a client device (see, 
e.g., page 4, lines 2-18, reference numeral 20 in Fig. 2) comprising: an ad-hoc client to manage 
connection of said client device to an ad-hoc wireless network (see, e.g., page 5, lines 6-12; 
reference numeral 26 in Fig. 2); a DHCP client to send a DHCP discover message in response to a 
command from said ad-hoc client (see, e.g., page 5, lines 3-6; reference numeral 24 in Fig. 2); and a 
tinyDHCP unit to sense said DHCP discover message and allocate an IP address for the client device 
in response thereto (page 5, line 13 to page 6, line 2; page 6, line 22 to page 7, line 27; reference 
numeral 28 in Fig. 2). 

Independent claim 14 of the present application is directed to a method for use in connecting 
a client device to an ad-hoc network comprising: (a) sending a DHCP discover message from within 
the client device; (b) receiving said DHCP discover message within the client device; and (c) 
allocating an IP address to the client device in response to receiving said DHCP discover message, 
within the client device. 
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For claim 14, examples are disclosed in the specification as filed at, for example, page 6, line 
16 to page 7, line 29 and Figs. 3-4. The exemplary embodiments disclose a method for use in 
connecting a client device to an ad-hoc network (see, e.g., page 6, lines 16-18) comprising: sending a 
DHCP discover message from within the client device (see, e.g., page 6, lines 21-22; reference 
numeral 44 in Fig. 3); receiving said DHCP discover message within the client device (see, e.g., 
page 6, lines 22-26; reference numeral 46 in Fig. 3); and allocating an IP address to the client device 
in response to receiving said DHCP discover message, within the client device (see, e.g., page 6, line 
27 to page 7, line 13; reference numeral 48 in Fig. 3). 

Independent claim 26 of the present application is directed to an article comprising computer 
readable storage media having instructions stored thereon that, when executed by a computing 
platform, result in: (a) sending a DHCP discover message from within a client device; (b) receiving 
said DHCP discover message within the client device; and (c) allocating an IP address to the client 
device in response to receiving said DHCP discover message, from within the client device. 

For claim 26, examples are disclosed in the specification as filed at, for example, page 6, line 
16 to page 7, line 29 and Figs. 3-4. The exemplary embodiments disclose an article comprising 
computer readable storage media having instructions stored thereon that, when executed by a 
computing platform, result in: sending a DHCP discover message from within a client device (see, 
e.g., page 6, lines 21-22; reference numeral 44 in Fig. 3); receiving said DHCP discover message 
within the client device (see, e.g., page 6, lines 22-26; reference numeral 46 in Fig. 3); and 
allocating an IP address to the client device in response to receiving said DHCP discover message, 
within the client device (see, e.g., page 6, line 27 to page 7, line 13; reference numeral 48 in Fig. 3). 

Independent claim 30 of the present application is directed to a client device comprising: (a) 
a wireless network interface card (NIC) to provide an interface to a wireless network medium; (b) an 
ad-hoc client to manage connection of said client device to an ad-hoc wireless network; (c) a DHCP 
client to send a DHCP discover message in response to a command from said ad-hoc client; and (d) a 
tiny DHCP unit to sense said DHCP discover message and allocate an IP address for the client device 
in response thereto. 

For claim 30, examples are disclosed in the specification as filed at, for example, page 3, 
lines 25-28; page 4, line 14 to page 6, line 2; and Figs. 2, 3, and 4. The exemplary embodiments 
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disclose a client device (see, e.g., page 4, lines 2-18, reference numeral 20 in Fig. 2) comprising: a 
wireless network interface card (NIC) to provide an interface to a wireless network medium (see, 
e.g., page 3, lines 25-28 and page 6, lines 9-1 1); an ad-hoc client to manage connection of said client 
device to an ad-hoc wireless network (see, e.g., page 5, lines 6-12; reference numeral 26 in Fig. 2); a 
DHCP client to send a DHCP discover message in response to a command from said ad-hoc client 
(see, e.g., page 5, lines 3-6; reference numeral 24 in Fig. 2); and a tinyDHCP unit to sense said 
DHCP discover message and allocate an IP address for the client device in response thereto (page 5, 
line 13 to page 6, line 2; page 6, line 22 to page 7, line 27; reference numeral 28 in Fig. 2). 

6. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Issue 1 - Whether claims 1-3,5-6. and 8-33 were properly rejected under 35 USC § 1 03(a) as 
being unpatentable over Gu (U.S. Publication No. 2004/0260800) (hereinafter Gu) in view of Okano 
(U.S. Publication No. 2002/0062485) (hereinafter Okano). 

Issue 2 - Whether claim 7 was properly rejected under 35 USC § 103(a) as being 
unpatentable over Gu in view of Okano and further in view of Gardiner (U.S. Publication No. 
2003/0225864) (hereinafter Gardiner). 

7. ARGUMENT 

Rejections Under 35 U.S.C. S 103(a) 
Legal Principles 

To support an obviousness rejection, it must be shown that "the differences between the 
subject matter sought to be patented and the prior art are such that the subject matter as a whole 
would have been obvious at the time the invention was made to a person having ordinary skill in the 
art to which said subject matter pertains." 35 U.S.C. § 103(a) [emphasis added]. In rejecting claims 
under 35 U.S.C. § 103, it is incumbent upon the Examiner to establish a factual basis to support the 
legal conclusion of obviousness. SeelnreFine, 837F.2d 1071, 1073 (Fed. Cir. 1988). The factual 
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inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 
for establishing a background for determining obviousness under 35 U.S.C. 103(a) are summarized 
as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating obviousness or 
nonobviousness. 

The U.S. Supreme Court has held that the analysis supporting a rejection under 35 U.S.C. § 103 

should be made explicit. KSR International Co. v. Teleflexlnc. (KSR), 550 U.S. , 82 USPQ2d 

1385 (2007). In KSR, the Court (quoting In re Kahn, 441 F.3d 977, 988, 78 USPQ2d 1329, 1336 
(Fed. Cir. 2006)) stated that "[Rejections on obviousness cannot be sustained by mere conclusory 
statements; instead, there must be some articulated reasoning with some rational underpinning to 
support the legal conclusion of obviousness." In determining the differences between the prior art 
and the claims, the question under 35 U.S.C. 103 is not whether the differences themselves would 
have been obvious, but whether the claimed invention as a whole would have been obvious. 
Stratoflex, Inc. v. Aeroquip Corp., 713 F.2d 1530, 218 USPQ 871 (Fed. Cir. 1983); Schenck v. 
Nortron Corp., 713 F.2d 782, 218 USPQ 698 (Fed. Cir. 1983). "All words in a claim must be 
considered in judging the patentability of that claim against the prior art." In re Wilson, 424 F.2d 
1382, 1385, 165 USPQ 494, 496 (CCPA 1970). 

L Rejections Under 35 U.S.C. § 103(a) over Gu in view of Okano 

A.) Claims 1-3, 5-6. and 8-33 were rejected under 35 USC § 103(a) as being unpatentable 
over Gu in view of Okano. 

Independent Claims 1 and 30 
Claim 1 is an independent claim directed to a client device comprising: (a) an ad-hoc client 
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to manage connection of said client device to an ad-hoc wireless network; (b) a DHCP client to send 
a DHCP discover message in response to a command from said ad-hoc client; and (c) a tinyDHCP 
unit to sense said DHCP discover message and allocate an IP address for the client device in 
response thereto. In a conventional network, a network server (commonly known as a DHCP server) 
is located somewhere within the network for distributing IP addresses to client devices within the 
network. When a client device needs an IP address, the device sends a message through the network 
to the server, requesting the address. The server may then select an IP address for the client device 
and send the address back to the client device through the network. In contrast, the client device of 
claim 1 has a tinyDHCP unit located within the client device itself that senses a DHCP discover 
message sent by a DHCP client within the client device and allocates an IP address for the client 
device in response thereto. It appears to the DHCP client that it is dealing with a remote DHCP 
server in the network and not functionality within the same client device. Thus, the claimed client 
device may be used in a network where there is no DHCP server available (e.g., an ad-hoc network). 

The Examiner rejected claim 1 based on a combination of Gu and Okano. In the final office 
action, the Examiner takes the position that Gu discloses a client device having the claimed "ad hoc 
client," the claimed "DHCP client," and a tinyDHCP unit "to sense a DHCP discover message." 
However, the Examiner indicates that Gu fails to disclose that the tinyDHCP allocates an IP address 
for the client device in response to the sensed DHCP discover message. The Examiner then argues 
that Okano teaches that it is well known to allocate an IP address for a client device in response to a 
DHCP discover message (i.e., using a DHCP server 10 within a cable TV center that is remote from 
the subscriber terminals (see paragraphs 0007-0009 of Okano)). In the rationale in support of the 
rejection, the Examiner describes a system that uses a DHCP server. Thus, the Examiner failed to 
ascertain the differences between the prior art and the client device of claim 1 and failed to show 
why "the differences between the subject matter sought to be patented and the prior art are such that 
the subject matter as a whole would have been obvious at the time the invention was made to a 
person having ordinary skill in the art to which said subject matter pertains" as required by 35 
U.S.C. § 103(a). 

Gu discloses a device that is capable of developing its own IP address when there is no 
DHCP server available in a corresponding network, but the device does not include functionality 
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that allows a DHCP client within the device to operate as if a DHCP server were available external 
to the client device. That is, Gu discusses the AutoIP protocol of Universal Plug and Play (UPnP) 
that allows a device to claim an IP address from a predetermined range (see paragraph [0532]). 

In the advisory action, the Examiner revised the rejection of independent claim 1 . The 
Examiner now takes the position that Okano discloses "intercepting a DHCP request from a terminal 
device, and assigning an IP address." The Examiner does not specify where Okano discloses this, 
but presents a sentence of text which is presumably from Okano. A text search of Okano shows that 
a first half of the sentence is from the Abstract section and a second half is from paragraph 0014 
(which is part of the background section). Thus, the Examiner is mixing a description of the 
invention of Okano (from the Abstract) with a description of the prior art of Okano (from the 
Background) into a single sentence in the advisory action to support his argument. In addition, the 
Examiner uses the word "so" between the sentence fragments as if to state that the second part of the 
sentence is caused by the first part of the sentence. 

It appears that the argument that the Examiner is attempting to make is that Okano discloses 
a cable modem that acts as a DHCP relay between a subscriber terminal and a remote DHCP server. 
As such the cable modem relays DHCP message from the subscriber terminal to the DHCP server, 
and vice versa. Thus, the cable modem intercepts a DHCP request from the subscriber station and 
transfers it to the remote DHCP server. The cable modem also receives an IP address from the 
DHCP server and transfers it to the subscriber device. However, even if this is true, it would not 
suggest to a person of ordinary skill in the art to include the claimed tinyDHCP unit within the client 
device itself. Even if the cable modem of Okano were moved into the subscriber terminal, this 
modification still would follow the prior art technique of using a remote DHCP server to "allocate" 
the IP address. Claim 1 recites "a tinyDHCP unit to sense said DHCP discover message and allocate 
an IP address for the client device in response thereto." That is, the DHCP is not simply a relay that 
relays messages back and forth. It is a unit that senses a DHCP discover message generated by a 
DHCP client within the client device and "allocates" and IP address for the client device "in 
response thereto." Therefore, the combination of Gu and Okano would not render the subject matter 
of claim 1, as a whole, obvious to a person of ordinary skill in the art. 

In addition to the above, the cable modem of Okano is separate from the subscriber station. 
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It is therefore not part of a single "client device" as required by claim 1 . To counter this argument, 
the Examiner cites In re Larson, 144 USPQ 347 (CCPA 1965) as holding that it is obvious to make 
things integral. However, In re Larson deals with the physical integration of mechanical parts that 
were previously abutting, but not integral. This case does not create a broad rule that it is always 
obvious to combine items into a single unit even when they were previously separately located. In 
addition, even if the cable modem and the subscriber terminal of Okano were combined, the result 
still would not teach or suggest the claimed subject matter. Thus, neither Gun nor Okano, either 
alone or in combination, teach or suggest a client device that includes "a tinyDHCP unit to sense 
said DHCP discover message and allocate an IP address for the client device in response thereto." 

In the advisory action, after citing In re Larson, the Examiner presents as a rationale for the 
rejection "With this in mind, one of ordinary skill in the art would find it obvious to combine the 
cable modem and the terminal as a single client device and therefore the rejection is maintained." 
This rationale does not address the clear differences between the claimed subject matter and the cited 
references and does not rise to the level of "articulated reasoning" envisioned by the Supreme Court 
in KSR. In addition, the Examiner fails to address the claimed subject matter "as a whole." 

Based on the foregoing, it is submitted that independent claim 1 is not rendered obvious by 
the combination of Gu and Okano. Allowance of claim 1 is therefore respectfully requested. 
Independent claim 30 should be allowable for at least the same reasons as independent claim 1. 

Independent Claims 14 and 26 

Independent claim 14 is directed to a method for use in connecting a client device to an ad- 
hoc network. More specifically, the method comprises: (a) sending a DHCP discover message from 
within the client device; (b) receiving said DHCP discover message within the client device; and (c) 
allocating an IP address to the client device in response to receiving said DHCP discover message, 
within the client device. Similar to claim 1, the actions a, b, c of claim 14, as set out above, are all 
taking place within the client device. The DHCP discover message is both sent and received within 
the client device and the IP address is allocated within the client device. This is not disclosed or 
suggested by the cited references (either alone or in combination). 

In the final office action the Examiner identifies the "Discover Listener" signal of Fig. 29 as 



the claimed "DHCP discover message" that is "sent," but the Examiner identifies the "Response to 
Discover" signal of Fig. 29 as the "DHCP discover message" that is "received." The Applicants 
respectfully disagree with this analysis. The Examiner identifies two separate signals in Gu to 
represent a single message in claim 14. That is, the claimed method sends a DHCP discover 
message from within the client device and also receives the same message within the client device. 
The client device 950 of Gu transmits a "Discover Listener" signal, but receives a "Response to 
Discover" signal, which is a different signal. Also, the "Discover Listener" and the "Response to 
Discover" messages of Gu are not DHCP messages as required by claim 14 (see paragraphs 0555 
and 0556 of Gu). In addition, neither of the references cited by the Examiner disclose or suggest, 
either alone or in combination, "allocating an IP address to the client device in response to receiving 
said DHCP discover message , within the client device ." 

With regard to independent claim 14, the Examiner fails to properly ascertain the differences 
between the prior art and the claimed invention as required by Graham. In addition, the Examiner 
fails to provide any articulated reasoning as to why the subject matter as a whole would have been 
obvious at the time the invention was made in light of the differences between the prior art and the 
claimed invention. Furthermore, the Examiner does not consider all of the words of the claim in 
judging the patentability of the claim. The DHCP discover message is both sent and received within 
the client device and the IP address is allocated within the client device. This is not disclosed or 
suggested by the cited references (either alone or in combination). 

In the advisory action, the Examiner revised the rejection of independent claim 14. That is, 
the Examiner presents substantially the same argument that was discussed above in connection with 
claim 1, involving the cable modem as a DHCP relay agent. The Examiner also repeats the 
argument that it is obvious to make something integral per the In re Larson. As described above, the 
applicants submit that these arguments are invalid. The rationale presented by the Examiner does 
not address the clear differences between the claimed subject matter and the cited references and 
does not rise to the level of "articulated reasoning" envisioned by the Supreme Court in KSR. In 
addition, the Examiner fails to address the claimed subject matter "as a whole." 

Based on the foregoing, it is submitted that independent claim 14 is not rendered obvious by 
the combination of Gu and Okano. Allowance of claim 14 is therefore respectfully requested. 
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Independent claim 26 should be allowable for at least the same reasons as independent claim 14. 

Dependent Claims 

Claims 2-3, 5-6, and 8-13, claims 15-25, claims 27-29, and claims 31-33 are dependent 
claims that depend either directly or indirectly from independent claims 1, 14, 26, and 30, 
respectively. Consequently, these claims are allowable for at least the same reasons as their 
corresponding base claims. These claims also provide further bases for patentability. 

Claims 2, 3. 19, 20, 32, 33 
Claim 2 adds "a packet driver" to the client device of claim 1 "to provide raw access to a 
wireless network medium for at least the tinyDHCP unit without using sockets functionality." 
Neither Gu nor Okano discloses or suggests such a packet driver. In the final action, the Examiner 
takes the position that Gu discloses a TCP/IP stack 958 (Winsock) and a network interface card that 
provide a physical connection to the computer network which do the same function as a packet 
driver. However, the claim specifically states that the claimed packet driver provides raw access to 
the medium "without using sockets functionality." The use of sockets functionality by Gu (i.e., 
Winsock) would not have been suggestive to a person of ordinary skill in the art to provide raw 
access to the medium "without using sockets functionality." A similar argument applies to claims 
19, 20, and 32. 

Claim 3 further defines the "packet driver" of claim 2 as being "part of a packet capture 
library." Neither Gu nor Okano disclose the such a packet capture library being used in conjunction 
with a tinyDHCP within a client device. A similar argument applies to claim 33. 

Claims 5, 15, 16, 27, and 28 
Claim 5 further defines the "DHCP client" of claim 1 as sending said DHCP discover 
message to a predetermined port that is monitored by said tinyDHCP unit. By monitoring the port to 
which the DHCP client sends the DHCP discover message, the tinyDHCP unit is able to sense the 
discover message and thus allocate the IP address in response thereto. Neither Gu nor Okano 
discloses or suggests this. A similar argument applies to claims 15, 16, 27, and 28. 



11 



Claims 8, 9. 10. 12. 17. 21. 23. 24, and 29 
Claim 8 further defines the "tinyDHCP unit" of claim 1 as sending a DHCP offer that 
includes the IP address. Claim 9 further defines the "tinyDHCP unit" of claim 8 as sending the 
DHCP offer to a predetermined port that is monitored by the DHCP client. Claim 1 0 further defines 
the "DHCP client" of claim 8 as sensing the DHCP offer and sending a DHCP request based 
thereon, wherein the DHCP request includes the IP address." Claim 12 further defines the 
"tinyDHCP unit" of claim 10 as sensing the DHCP request and sending a DHCP acknowledge 
(ACK) message in response thereto. Neither Gu nor Okano discloses or suggests the use of any of 
these features within a client device. Similar arguments apply to claims 17, 21, 23, 24, and 29. 

II. Rejections Under 35 U.S.C. 103(a) over Gu in view of Okano 
and further in view of Gardiner 

Claim 7 was rejected under 35 USC § 103(a) as being unpatentable over Gu (U.S. 
Publication No. 2004/0260800) in view of Okano (U.S. Publication No. 2002/0062485), further in 
view of Gardiner (U.S. Publication No. 2003/0225864). 

Claim 7 is a dependent claim that depends indirectly from independent claim 1. 
Consequently, this claim is allowable for at least the same reasons as independent claim 1 . 



12 



8. SUMMARY 

For the reasons advanced above, the Appellant respectfully submits that all of the pending 
claims are in form for allowance. Therefore, reversal of all rejections is respectfully requested. 



Respectfully submitted, 
RAVIKUMAR MOHANDAS 
By his Representatives, 



Date August 2 1 , 2008 By 



Customer Number 45643 




John C. Scott 
Reg. No. 38,613 



CERTIFICATE UNDER 37 CFR 1.8: The undersigned hereby certifies that this correspondence is being deposited with the 
United States Postal Service with sufficient postage as first class mail, in an envelope addressed to: Mail Stop Appeal Brief, 
Commissioner of Patents, P.O. Box 1450, Alexandria, VA 22313-1450, on this 21st day of August 2008. 




Shellie Bailey 
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APPENDIX I 

The Claims on Appeal 



1 . (Original) A client device comprising: 

an ad-hoc client to manage connection of said client device to an ad-hoc wireless network; 
a DHCP client to send a DHCP discover message in response to a command from said ad- 
hoc client; and 

a tinyDHCP unit to sense said DHCP discover message and allocate an IP address for the 
client device in response thereto. 

2. (Original) The client device of claim 1, further comprising: 

a packet driver to provide raw access to a wireless network medium for at least the 
tinyDHCP unit without using sockets functionality. 

3. (Original) The client device of claim 2, wherein: 
said packet driver is a part of a packet capture library. 

4. (Canceled) 

5. (Original) The client device of claim 1, wherein: 

said DHCP client sends said DHCP discover message to a predetermined port that is 
monitored by said tinyDHCP unit. 

6. (Original) The client device of claim 1, wherein: 

said tinyDHCP unit tests the availability of said IP address. 

7. (Original) The client device of claim 6, wherein: 

said tinyDHCP unit tests the availability of said IP address by sending an ICMP echo 
request. 
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8. (Original) The client device of claim 1, wherein: 

said tinyDHCP unit sends a DHCP offer that includes the IP address. 

9. (Original) The client device of claim 8, wherein: 

said tinyDHCP unit sends said DHCP offer to a predetermined port that is monitored by said 
DHCP client. 

10. (Original) The client device of claim 8, wherein: 

said DHCP client senses said DHCP offer and sends a DHCP request based thereon, wherein 
said DHCP request includes said IP address. 

1 1 . (Original) The client device of claim 1 0, wherein: 

said DHCP client verifies availability of said IP address before sending said DHCP request. 

12. (Original) The client device of claim 10, wherein: 

said tinyDHCP unit senses said DHCP request and sends a DHCP acknowledge (ACK) 
message in response thereto. 

13. (Original) The client device of claim 1, wherein: 

said tinyDHCP unit is associated with a user interface to allow a user to specify DHCP 
parameters. 

1 4. (Original) A method for use in connecting a client device to an ad-hoc network, comprising: 
sending a DHCP discover message from within the client device; 

receiving said DHCP discover message within the client device; and 
allocating an IP address to the client device in response to receiving said DHCP discover 
message, within the client device. 
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15. (Original) The method of claim 14, wherein: 

sending includes sending said DHCP discover message to a predetermined port. 

16. (Original) The method of claim 15, wherein: 

receiving includes monitoring said predetermined port and sensing said DHCP discover 
message on said predetermined port. 

17. (Original) The method of claim 14, further comprising: 

sending a DHCP offer that includes said IP address, after allocating said IP address, from 
within the client device. 

18. (Original) The method of claim 17, further comprising: 

testing the availability of said IP address before sending said DHCP offer. 

19. (Original) The method of claim 17, wherein: 

sending a DHCP offer includes causing a packet driver to send said DHCP offer on a 
wireless network medium. 

20. (Original) The method of claim 19, wherein: 

said packet driver sends said DHCP offer on said wireless network medium without the use 
of sockets functionality. 

21. (Original) The method of claim 17, further comprising: 
receiving said DHCP offer within the client device; and 

sending, after receiving said DHCP offer, a DHCP request that includes said IP address from 
within the client device. 

22. (Original) The method of claim 21, further comprising: 

verifying that the IP address within the DHCP offer is available before sending said DHCP 
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request. 



23. (Original) The method of claim 21, further comprising: 
receiving said DHCP request within the client device; and 

sending, after receiving said DHCP request, a DHCP acknowledge (ACK) message from 
within the client device. 

24. (Original) The method of claim 23, further comprising: 
receiving said DHCP ACK message within the client device. 

25. (Original) The method of claim 14, wherein: 
allocating includes using dynamic DHCP allocation. 

26. (Previously Presented) An article comprising computer readable storage media having 
instructions stored thereon that, when executed by a computing platform, result in: 

sending a DHCP discover message from within a client device; 
receiving said DHCP discover message within the client device; and 
allocating an IP address to the client device in response to receiving said DHCP discover 
message, from within the client device. 

27. (Original) The article of claim 26, wherein: 

sending includes sending said DHCP discover message to a predetermined port. 

28. (Original) The article of claim 27, wherein: 

receiving includes monitoring said predetermined port and sensing said DHCP discover 
message on said predetermined port. 

29. (Original) The article of claim 26, further comprising: 

sending a DHCP offer that includes said IP address, after allocating said IP address, from 
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within the client device. 

30. (Original) A client device comprising: 

a wireless network interface card (NIC) to provide an interface to a wireless network 
medium; 

an ad-hoc client to manage connection of said client device to an ad-hoc wireless network; 
a DHCP client to send a DHCP discover message in response to a command from said ad- 
hoc client; and 

a tinyDHCP unit to sense said DHCP discover message and allocate an IP address for the 
client device in response thereto. 

3 1 . (Original) The client device of claim 30, wherein: 

said wireless NIC is configured in accordance with the IEEE 802.1 1 wireless networking 
standard. 

32. (Original) The client device of claim 30, further comprising: 

a packet driver to provide raw access to said wireless network medium for the tinyDHCP unit 
without using sockets functionality. 

33. (Original) The client device of claim 32, wherein: 
said packet driver is part of a packet capture library. 

34. (Canceled) 
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